This description generally relates to database cryptography, and more particularly to database write protection.
Online computer databases are vulnerable to a variety of different types of attacks by third parties. Often, the goal of these attacks is to be able to obtain read access, and therefore access to the substantive contents of the database. To prevent such breaches, online systems have grown more robust over time. One tool in breach prevention is using one or more cryptographic primitives to securely store passwords that permit read access. Cryptographic primitives include using salts, one way functions (e.g., hash functions), cryptographic operations (e.g., encryption, decryption), symmetric cryptography schemes, and asymmetric (or public key) cryptography schemes. Another major tool in breach prevention is using a separate cryptography service to perform various tasks associated with database access, including applying cryptographic primitives as mentioned above. For example, one type of cryptography service involves using a physically separate computing device, one example of which is referred to as a hardware security module (HSM), that is specially designed to securely store cryptographic keys and perform cryptographic processing.
For many online databases, merely having the database breached and read by an intruder is a worst case scenario that merits most if not all of the attention of the online system's security staff. As a result, many online systems do not implement database write protection on top of read protection because all the harm has been done once the database has been read.
For some online systems, however, write protection is at least as important as read protection, and thus merits attention. For example, for an online payments system, breaches that write data to a database can have catastrophic financial implications of their own. FIGS. 2A-2C contains several examples of database write attacks that can cause problems for an online system.
FIG. 2A illustrates an example bank account table containing bank account numbers for a number of users in an online payments system that provides payouts to users. While a read attack that obtains user bank account numbers would be problematic on its own, also problematic would be a write attack that replaces the bank account number of a user with the bank account number of an attacker, for example. As an illustration, if Alice's account number abc123 were overwritten with the attacker's account number def456, any payments that were intended to go to Alice would instead go to the attacker. Such a write attack is dangerous not only due to losses by Alice and the online system, but also because no read attack is needed to cause harm. Alternatively, Alice's account number could be written to another row in the table accessible by the attacker (e.g., Bob's row), who could then read the account number without needing to perform a read attack.
FIG. 2B illustrates a similar example bank account table and an example credit card table. In this example, rather than overwriting or copying data within a single table, a write attack could write data between tables. Some of these attacks may result in erroneous or non-functional behavior in the online system, for example account numbers and credit card numbers may not be able to be written between tables based on the sizes and data types of those columns. These attacks may also result in errors in the business logic implemented on top of the database by the online system, depending upon how these different columns of data are used once read out of the database. However, some of these attacks may result in data that was previously protected by rigorous business logic to become openly visible to the attacker. For example, a column data that was previously protected by a password system may instead end up being visible through an unprotected portion of the web interface provided by the online system. Here, write attacks provide a way to circumvent read protection or other security mechanisms implemented by the online system.
FIG. 2C illustrates another example bank account table. In this example, rather than overwriting or copying elsewhere the data item of interest, a write attack may instead change the data in the surrounding cells in the same row of the table. For example, a write attack may change the bank routing number associated with a user's account, as well as the contact email address for that user. If the attacker controls the account number at the bank corresponding to the new routing number, then any payments made to that user would be redirected to the attacker. Further, emails directed to the account holder may be redirected to an email account associated with the attacker, thus preventing the real account holder from receiving valuable information from the online system about the breach.